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ABSTRACT 

The Solar Anomolous and Magnetospheric Explorer 
(SAMPEX) satellite was launched in July 1992. It was 
the first in the NASA Small Explorer (SMEX) series. 

In building the real-time control center facility, several 
new mission support challenges had to be met; 

(a) CCSDS telemetry and command format, (b) 900 
Kbps telemetry data , and (c) shorter turn-around time 
for control center development than previous missions 

The SAMPEX Payload Operations Control Center 
(POCC) was also the first control center for a new 
satellite to be based on the Transportable Payload 
Operations Control Center (TPOCC) system 
architecture and methodology. This approach has both 
guided the implementation of the SAMPEX control 
center and provided some of the building blocks. By 
using the TPOCC architecture to build the SAMPEX 
POCC, the real-time operations area was miniturized 
into one room, whereas previous missions needed 
multiple large rooms. The development cost of the 
SAMPEX POCC was reduced from previous missions 
and will provide for futher cost savings in the future 
SMEX satellites. 

This paper describes the system as built and some of the 
enhancements in progress to create this teleoperations 
environment. 

Key Words: Spacecraft control center. Payload 
Operations Control Center, Teleoperations 

1. INTRODUCTION: 

The Control Center Systems Branch (CCSB) of the 
Mission Operations Division (MOD) at the NASA 
Goddard Space Flight Center was tasked with the 
creation of the Payload Operation Control Center 
(POCC) for Solar Anomalous Magnetospheric Particle 
Explorer (SAMPEX). The CCSB has created POCCs 
for such satellites as the Cosmic Background Explorer, 
the Gamma Ray Observatory, the Upper Atmosphere 
Research Satellite and the Extreme Ultraviolet 


Explorer. Presently POCCs are being developed for 
missions such as the Interplanetary Physics 
Laboratory (WIND), the Polar Plasma Laboratory 
(POLAR), the Solar Oscillator Heliospheric 
Observatory (SOHO), the X-Ray Timing Explorer 
(XTE), and the Tropical Rainfall Measuring 
Mission (TRMM). 

SAMPEX is the first in a series of NASA Small 
Explorer (SMEX) satellites. The SMEX satellites 
were intended to be low cost and to be launched 3 
years from conception. The SAMPEX mission is a 
relatively simple mission whose purpose is to 
measure the elemental and isotopic composition of 
ions emitted from the sun with energies over the 
range from one to several hundred megaelectron 
volts. However, the fact that the mission was 
simple did not translate into a simple ground 
system. Although the SMEX series of satellites 
were specified as low cost missions, with the low 
cost being achieved via the use of less redundancy 
and higher risk operations, the higher risk 
introduced into the space segment introduced 
additional requirements into the ground system in 
order to assure the health and safety of SAMPEX. 
Also, SAMPEX was the first satellite to introduce 
the use of the Small Explorer Data System (SEDS) 
as the on board computer. The SEDS is a 80386- 
CPU based computer and features dynamic memory 
management. The SEDS, although allowing for 
greatly enhanced capabilities for the Flight 
Operations Team (FOT), introduced an additional 
level of complexity in terms of managing the flight 
software, tables and the stored command 
processors. The SEDS features a 32 Mbyte solid 
state recorder which permits recorded telemetry to 
be dumped data in forward order and for data to be 
stored and dumped simultaneously. 

2. CHALLENGES: 

There were a number of compelling challenges in 
the creation of the SAMPEX POCC. The greatest 
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challenge was the relatively short development cycle. 
The launch date was driven by both a need to launch 
as close as possible to the solar maximum and the 
desire by NASA to demonstrate that low cost, quick 
turnaround missions were feasible. In light of 
ongoing budget cuts, streamlining of mission costs has 
become a primary driver for NASA's projects. In the 
past, launch has typically occurred more than 36 
months after the POCC System Requirements Review 
(SRR). For SAMPEX, launch occurred in only 20 
months after the POCC SRR. This consolidation of 
the schedule occurred only through a dedicated 
team effort in which many traditional development 
and testing methods had to be modified to increase 
efficiency. 

Another challenge was the use of the CCSDS 
protocol, which is a packet based approached for both 
command uplinks and telemetry downlinks. The 
challenge with CCSDS was that there was no 
operationally proven equipment or software upon 
which to base thecreation of the SAMPEX POCC 
system. 

A third challenge was that the telemetry data rate to 
be processed by the POCC and other elements of the 
ground system was 900 Kbps. This was a much 
higher rate than the MOD had previously dealt with. 
New block and frame synchronization equipment had 
to be developed. The engineering real-time data rate 
was only 16 kbps, but was enveloped in the higher 
data rate composite stream primarily comprised of 
science data. 

Finally, SAMPEX was the first new mission created 
using the Transportable Payload Operations Control 
Center (TPOCC) core software and hardware 
components. The use of the TPOCC 
architecture presented challenges in coordinating the 
TPOCC and SAMPEX mission specific efforts and in 
educating the Flight Operations Team (FOT) 
personnel about a new operations approach. 

3. SAMPEX POCC FUNCTIONAL 
REQUIREMENTS: 

The high level functional requirements of the 
SAMPEX POCC were as follows: 

(1) Provide reception and processing 

capabilities for telemetry data 

(2) Provide the capability to playback satellite 

recorder data and process the recorder 


engineering data portion similar to the way 
that realtime engineering data is processed 
following pass completion. 

(3) Provide real-time commanding 

(4) Provide displays and reports to monitor 

telemetry processing and commanding. 

(5) Provide command panel user interface 

(6) Provide a high level language (System 

Test and Operations Language) to control all 
POCC functions. 

(7) Accept project provided database of 
telemetry points and commands. 

(8) Provide equipment and facilities for the 
POCC. 

4. MANAGEMENT APPROACH: 

The management approach for developing the 
SAMPEX POCC was different from previous POCCs. 
The SAMPEX POCC is based on the TPOCC 
architecture and, therefore, also inherited its 
management approach. In particular, custom software 
and hardware solutions are avoided as much as 
possible. By maximizing the use of Custom 
Off The Shelf (COTS) hardware and software, the 
CCSB hopes to harness the synergy derived when 
industry focuses on standards. 

The compliance with these standards allows for many 
of the POCC features to be provided as COTS 
components. Those features which cannot be 
purchased from industry are, developed in-house and 
manufactured as reusable components, whether 
hardware or software. The TPOCC group acts as a 
focal point for system baselining of the core 
functionality for SAMPEX and other TPOCC- 
based POCC development efforts. 

All of this translates into maximizing both reuse and 
flexibility. Over many years of POCC development, 
we have learned that requirements for POCCs tend to 
develop as operational requirements mature. 
Requirements can rarely be cast in concrete and 
therefore flexibility is a must. There are always 
changes requested and the quicker these changes can 
be accomodated, the lower the ultimate cost of 
development. The initial effort of creating a very 
flexible system tends to be higher than tailoring the 
system, however, in the long run there is greater 
system flexibility and cost savings by following this 
approach. 

This flexibility was evident in the SAMPEX POCC 
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development effort. POCC software was being 
developed for the SAMPEX and WIND/POLAR 
missions simultaneously with the implementation of 
the core TPOCC software. In order to ensure that the 
functionality needed for SAMPEX would be available 
and meet mission requirements on schedule, 
implementation of essential TPOCC generic software 
was coordinated and shared among the TPOCC and 
TPOCC-based mission groups. Second, the core 
telemetry processing capabilities were prototyped by 
the SAMPEX POCC group during its design phase to 
ensure that the high telemetty data rate could be 
supported by the proposed hardware/software 
configuration. The coordination of implementation 
and early prototyping was critical in meeting the short 
POCC system development schedule. 

Following industry standards not only allows COTS 
software to be incorporated into TPOCC, but also 
provides a path for incorporating software from other 
sources. For example, when groups external to 
TPOCC come up with good ideas or useful software, 
the TPOCC group will integrate these ideas or 
software into the core set of functionality so that all 
TPOCC based POCCs have access. An example of 
this is the ongoing effort to integrate the Generic 
Spacecraft Analyst Assistant (GenSAA), which is an 
expert system package which allows the operator to 
generate data driven diagrams and rule based 
processes. 

But the real power in the management approach is the 
empowerment of the members of the TPOCC 
development team via the formation of a TPOCC 
working group. The TPOCC working group includes 
all users of TPOCC and the TPOCC group itself, 
contractor and government, to make decisions as to 
how the system will work. Team effort is emphasized 
with the main goal being to improve the TPOCC 
system in line with evolving POCC requirements from 
the various missions. Emphasis is placed on doing it 
right the first time rather than depending on external 
quality control. 

5. DESIGN APPROACH: 

The design approach taken for the SAMPEX POCC 
was to provide functional strings of equipment 
consisting of workstations and X-terminals 
interconnected with a VME-based Front End 
Processor (FEP) via ethemet. Each string provides 
full independent POCC functionality (see fig 1). A 
prime and backup string are provided in the MOR, 


with each string having two operator positions. In 
addition, SAMPEX required three additional strings 
with 4 operator positions each which was provided in 
the launch and early orbit support facility called the 
Special Opeations and Test Area (SOTA). During 
launch, each position was used by two people allowing 
32 people to have display screens. The real-time 
functions reside in the front end with all of the user 
interface functions and some of the less time-critical 
functionality residing in workstations on the string. 

Industry standards that were used in developing the 
POCCsystem were as follows: 

(1) Unix & C 

(2) X windows & MOTIF compliant software 

(3) VME based hardware for the real-time FEP 

(4) Ethemet, TCP/IP 

(5) Unify 

The POCC functionality is partitioned between the 
FEP and the workstations. It should be noted that the 
FEPs run under VxWorks which is a real-time Unix- 
like operating system; whereas the workstations run 
under standard Unix. The following are the functions 
that ran in the FEP: 

(1) State manager- manages and coordinates all of 

the real-time POCC functions and the 
different states they can attain 

(2) Events- logs and alerts operator of events that 

the operator needs to know such as the 
occurrence of errors in the data or the 
acquisition of data 

(3) GMT- inputs NASA 36 time for labeling of 

displays, reports and events as appropriate 

(4) Data services- distributes requested data to 

other processes on the network. Acts as data 
traffic cop. For example, a certain plot may 
request 4 parameters at 5 second intervals. 

(5) External Communications- Controls hardware 

which does NASCOM deblocking, frame 
synchronization and packet processing 

(6) Telemetry- decommutates the telemetry which 

resides in CCSDS packets and was received 
from the NASCOM deblocker and frame 
synchronizer and places the data in 
a memory current value table for access by 
the data server. 

(7) History services- records incoming NASCOM 

blocks and incoming transfer frames. Also 
allows for playback of this data. 

(8) Initialization & termination- Allows for start 
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up and termination of front end across 
network. 

(9) Command- Accepts and formats real-time 
commands and command loads for uplink 

Each workstation on a string hosts the remainder of 
the functionality as follows: 

(1) Display- Provides displays of telemetry, 

telemetry status, command status, image 
dump status 

(2) TPOCC System Test and Operations Language 

(TSTOL)- Provides high level English 
commands for operator inputs. Also allows 
privilege classes and procedure generation. 

(3) File management- Manages files on 

workstations 

(4) Database- Accepts project database and 

transform into operational data base. 

(5) Reports- Generates required reports for users 

(6) Initialization and termination- Start and stop 
workstation 

6. TESTS APPROACH: 

The testing methodology of the SAMPEX POCC 
system was modified from the traditional approach 
due to time constraints. Typically, testing occurs in 
four phases: unit testing, system testing, acceptance 
testing and mission readiness testing. Typically, each 
phase might take 4-6 weeks. For the SAMPEX 
POCC, these phases were overlapped. For instance, 
the acceptance testers and the mission readiness 
testers received access to a system release about half 
way through system testing. This not 
only allowed early support of spacecraft testing but 
also served to provide feedback on problems in the 
system earlier in the development cycle. 

The main test tool for the developers and the 
acceptance testers was the TPOCC Advanced Satellite 
Simulator (TASS). TASS is a TPOCC based 
simulator that outputs simulated telemetry data and 
accepts commands. TASS runs on the same type of 
FEP and workstation used by SAMPEX, so no 
additional equipment was required. 

The FOT and the mission readiness testers used the 
Portable Satellite Simulator (PSS) and the actual 
spacecraft for testing. The PSS was a PC-based 
system that functioned very similar to TASS. The 
PSS was developed independently by a different group 
within the MOD. 


Surprisingly, this compressed testing schedule resulted 
m software releases with less discrepancies. Most 
likely, this was due to the fact that the time criticality 
caused all users to look at the system in a more timely 
manner. In fact, launch was supported with two 
official releases and a few patches as compared to the 
four delivered for more traditional missions. We hope 
to use some of these tighter coupling concepts (minus 
the increased stress) between the developers and the 
testers in future SMEX missions to increase 
productivity. 

7. FACILITIES: 

The real-time operations area was housed in the 
SMEX Mission Operations Room (MOR) . The off - 
line analysis area and the Command Management 
System (CMS) workstations were housed in the 
SMEX Mission Analysis Room (MAR). The SOTA 
served as a launch and early orbit support facility to 
accommodate all of the extra personnel who attended 
launch. The total space requirement for real-time 
operations (MOR) was less than 700 sq. ft. The MAR 
occupies another 680 sq. ft. 

8. LESSONS LEARNED: 

The main lessons learned in developing the SAMPEX 
POCC concerned what it takes to produce a POCC for 
a mission at lower cost and faster turn-around time. 
Although a large part of reducing cost thus far has 
been accomplished through the use of COTS software 
and hardware and the creation of reusable TPOCC 
software, the lowering of costs in the future will 
probably occur primarily through some restructuring 
of the management and development process. 

The goal of TPOCC has been to develop a core 
functionality which represents at least 80% of the 
functionality required by each new POCC. It is 
estimated that there will be approximately 85% 
reusability for the second SMEX mission which is 
Fast Auroral Snapshot Explorer (FAST). For the 
SAMPEX POCC, developers used about 60-70% of 
reusable TPOCC code. SAMPEX realized about a 
25% cost reduction over traditional CCSB POCC 
development efforts. Continued cost reductions on 
future SMEX satellites will depend less on the amount 
of increased reusable software and more on 
the following: 

(1) Cooperation between users and developers in 
specifying requirements, in particular the 
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streamlining of the requirements gathering 
process 

(2) Reduction of traditional presentations and 

paper to bare minimum and only to specify 
differences from previous missions in the 
series 

(3) Additional streamlining of testing 

(4) Continued emphasis on teamwork between the 

various contractor and government personnel 

Some of the ideas to be incorporated for additional 
streamlining of testing are: 

(1) Early involvement of the testers in the 

development process so that the testers can 
help to catch problems earlier in development 
phase. The cost of resolving a problem is 
inversely proportional to how early in the 
development phase it is cost. An error 
caught during a design walkthrough has 
minimal impact, whereas an error caught on 
an operational release involves the effort of a 
few people to produce an audit trail, fix the 
actual problem and to retest the system. 

(2) Early involvement by the testers will also allow 

input to the developers as to the testability of 
the system. 

(3) Early involvement by the testers will allow 

their input into our primaiy test tool which is 
TPOCC Advanced Satellite Simulator 
(TASS). 

(4) Early involvement of the flight operations 

team and the mission readiness testers in the 
development process. Their detection of 
errors can be different since some of their 
discrepancies reported involve the actual 
operations of the satellite. As the actual 
users of the system, the FOT provided a 
different insight into using the system. 



SAMP EX MISSION MOR 


(5) Test as much as possible in the actual 

operational environment. Seemingly small 
differences in environment became magnified 
during the stress of prelaunch system 
checkout. 

9. FUTURE ENHANCEMENTS: 

Future enhancements to the SMEX MOR will allow 
for multiple simultaneous satellite supports. The 
SAMPEX MOR contains two POCC strings, one 
designated as the primary string and one as backup. 

A third string will be added for FAST, the second 
SMEX satellite, giving each mission a dedicated 
primary string and a shared backup. When SWAS, 
the third SMEX satellite, is launched, the 
three POCC strings will need to be shared among the 
three SMEX satellites. One scenario for supporting 
all three satellites is to dedicate each string to one 
satellite, but also to allow any string to provide backup 
support for any satellite. This scenario will be 
accomplished by scheduling of the equipment and 
carefully planning operations 

Also, with most of the core POCC functionality 
complete, theTPOCC group will focus on adding 
enhanced user interface tools and off-line processing 
capabilities. Some of the tools being developed both 
internal and external to the CCSB are: 

(1) GenSAA (previously mentioned) 

(2) Space Views, a three dimensional visualization 

tool for flight operators and analysts 

(3) Orbital Signature Analyzer, pattern 

recognition tool to monitor the health and 
safety of a spacecraft by analyzing 
the shape of a plot 


(4) Trend analysis tool box- Off-line tool to 
perform statistics calculations and trend 
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